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I.  INTRODUCTION 

A.      OBJECTIVE 

The  purpose  of  this  thesis  is  to  design  and  implement  a  Microsoft  Windows-based 
database  system.  This  will  significantly  decrease  the  labor  hours  consumed  in  the 
generation  of  travel  orders  and  travel  claims  within  the  Administrative  Sciences 
Department  at  the  Naval  Postgraduate  School.  The  manual  system  currently  in  place  will 
be  replaced  by  a  single  point  data  entry  system  in  which  repetitive  tasks  will  be 
automated  to  the  greatest  extent  possible.  The  practice  of  reentering  data  for  each  travel 
order  and  travel  claim  will  be  eliminated.  The  system  will  produce  computerized  reports 
which  meet  external  reporting  requirements  while  providing  the  ability  to  generate 
custom  internal  reports  on  an  ad-hoc  basis.  The  Microsoft  Windows-based  system  will 
require  minimal  computer  knowledge  by  the  end-user.  The  application  is  written  using 
OMNIS7  Integrated  Development  Environment  and  is  implemented  on  a  Microsoft 
Windows-based  personal  computer. 

Travel  Database  System  is  a  Windows  based  application  that  allows  the  travel  clerk 
to  enter  a  complete  record  through  the  entry  of  multiple  data  fields  in  related  windows. 
The  application  provides  a  method  for  retrieving,  editing,  deleting,  inserting  records.  The 
system  is  tailored  to  produce  the  DD  1610,  NAVPERS  1320  and  the  DD  1351. 


B.       TRAVEL  DATABASE  SYSTEM:  AN  OVERVIEW 

The  Travel  Database  System  (TDS)  is  developed  to  enhance  the  ability  of  the 
Administrative  Sciences  Department  to  automate  the  generation  of  travel  orders  and 
travel  claims  for  both  civilian  and  military  personnel.  To  accomplish  this  goal  a  detailed 
analysis  of  the  required  input  forms  and  output  reports  was  conducted.  From  this  the 
flow  of  information  as  well  as  the  unique  attributes  associated  with  each  was  determined. 
The  DD  1610,  NAVPERS  1320  and  the  DD  1351  forms  were  used  as  the  basis  for  the 
initial  data  structure.  User  requirements  were  determined  through  extensive  interviews. 
The  requirements  were  transformed  into  a  prototype  system  which  was  demonstrated  to 
the  prospective  end-users.  To  meet  specific  user  requirements,  the  advanced  features  of 
the  development  environment  were  taken  advantage  of. 

The  underlying  structure  of  OMNIS7  eliminated  the  requirement  of  using  common 
fields  to  create  a  link  between  objects.  This  system  is  developed  using  Blythe  Software's 
OMNIS7  Integrated  Development  Environment,  version  1.03. 


II.  DEFINITION  PHASE 

The  first  phase  of  an  application  development  is  to  define  what  the  project  will  do. 
The  project  may  be  to  modify  an  existing  application,  develop  a  comprehensive  set  of 
applications  around  a  common  database,  or  automate  a  manual  data  related  task.  The 
definition  can  be  determined  by  a  team  of  experts  working  together  or  through  a  series 
of  interviews  or  a  combination  of  both  of  these.  The  scope  of  the  project  is  determined 
during  the  definition  phase  (i.e.,  what  will  be  included  as  necessary  functions  as  well  as 
what  would  be  extraneous  functionality).  The  final  function  of  the  definition  phase  is 
determining  the  feasibility  of  the  project.  Feasibility  includes  cost,  technical  and 
schedule.  [Ref  3:  pg.  75] 

A.      SCOPE  OF  THE  PROJECT 

The  goal  of  this  project  was  to  automate  and  track  Temporary  Additional  Duty 
orders  and  travel  claims  generation.  A  determination  was  made  that  all  work  could  be 
accomplished  on  a  single  IBM-compatible  386  computer  operating  under  Microsoft 
Windows  using  4mb  RAM.  The  project  was  scheduled  to  run  from  March  92  to  June  92. 
An  extension  until  September  92  was  granted  due  to  the  complexity  of  the  OMNIS7 
Integrated  Development  Environment.  System  functionality  requirements  were  determined 
during  interviews  with  members  of  the  Administrative  Sciences  Department  as  well  as 
those  members  of  the  staff  for  whom  the  application  was  designed. 


The  requirements  which  were  agreed  upon  included  the  following: 

1.  Microsoft  Windows  based  application  developed  using  the  OMNIS7  Integrated 
Development  Environment 

2.  A  data  structure  was  to  be  developed  which  would  link  the  required  reports  to  the 
personnel  data  file  format. 

3.  The  on-screen  editor  would  resemble  the  actual  form  as  closely  as  possible. 

4.  On-screen  editing  and  updating  of  forms  could  be  completed  easily. 


III.  REQUIREMENTS  PHASE 

The  requirements  phase  is  the  one  during  which  the  determination  is  made  of 
exactly  what  it  is  that  the  system  will  do.  The  goals  of  the  system  are  delineated.  The 
methods  for  determining  the  scope  of  the  user's  requirements  are  varied.  Interviews  are 
sometimes  ineffective  as  the  users  themselves  do  not  have  the  knowledge  to  put  forth 
pertinent  questions.  In  this  case  it  is  up  to  the  design  team  to  sound  the  users  for 
concepts  of  what  it  is  they  need.  The  design  team  may  use  a  prototype  which  includes 
sample  forms,  reports  and  menus  to  give  the  end  user  an  idea  of  the  capabilities  of  the 
proposed  system.  [Ref.  3:pg  77] 

A.      METHODOLOGY 

Interviews  were  conducted  with  the  members  of  the  Administrative  Sciences 
Department  for  whom  the  application  would  be  developed.  The  administrative  assistant 
described  functional  requirements  in  great  detail.  The  professors  supervising  the 
development  provided  the  information  related  to  the  underlying  data  structure. 

The  process  of  producing  a  prototype  system  from  the  initial  requirements  and  its 
first  version  was  reviewed  by  the  supervising  professor.  Minor  changes  in  the  screen 
displays  were  requested.  This  process  required  just  one  iteration.  The  final  version  was 
delivered  and  deemed  acceptable  both  by  the  end  user  and  the  supervising  professor.  The 
prototype  was  installed,  allowing  enough  time  for  the  developer  to  make  minor  changes 


in  structure  and  report  format.  An  in  depth  tutorial  for  the  end  user  was  provided  by  the 
system  developer. 

B.      DATA  REQUIREMENTS 

In  a  relational  database  structure  the  underlying  entity  is  an  object.  In  the  OMNIS7 
Integrated  Development  Environment  the  individual  objects  are  defined  by  file  formats, 
as  shown  in  Tables  1  through  5.  It  was  determined  that  a  total  of  four  file  formats  would 
need  to  be  developed.  The  formats  which  comprise  the  data  structure  of  the  TDS  are 
PERSDATA.DF1,  DD1610.DF1,  NP1320.DF1  and  DD1351.DF1.  The  file  formats  are 
linked  using  the  Record  Sequencing  Number  (RSN)  feature. 

The  PERSDATA.DF1  file  format  is  comprised  of  data  and  object  properties,  which 
comprise  each  personnel  record  in  the  personnel  file.  This  is  the  information  which  is 
required  for  the  personnel  information  portion  of  the  DD  forms  1610  and  1351  as  well 
as  the  NAVPERS  form  1320.  The  PERSDATA.DF1  represents  the  parent  file  format  in 
the  parent-child  file  format  relationship  as  shown  in  Figure  1 . 


PERSONNEL 


DD1610 


NAVPERS1320 


DD1351 


Figure  1.  Relational  Diagram 


The  file  format  DD1610.DF1  is  a  child  file  format.  This  format  has  an  optional 
Many(DD1610)-to-One(PERSDATA)  relationship.  The  file  format  NP1320.DF1  is  also 
a  child  of  PERSDATA  and  shares  the  same  relationship  as  the  DD1610  file  format.  The 
DD1351.DF1  file  format  is  a  child  of  both  the  DD 1610  and  the  NP1320  file  formats. 
This  file  format  shares  an  optional  One-to-One  relationship  with  it's  parent  file  formats. 
See  Figure  2. 
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Figure  2.  File  Format  Relationship 


C.      UPDATE,  DISPLAY  AND  CONTROL  MECHANISMS 

In  order  to  complete  the  development  of  a  database  application  the  user-system 
interactions  must  be  delineated.  In  the  case  of  TDS  this  meant  developing  a  plan  for  the 
user  to  make  his/her  way  through  a  series  of  data  display  windows  while  manipulating 
the  required  data.  (See  Data  Flow  Diagrams  depicted  in  Figures  3  and  4). 
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Figure  3.  Context  Level  Dataflow  Diagram 
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Figure  4.  System  Level  Dataflow  Diagram 

The  data  flow  begins  with  a  government  traveler  submitting  a  travel  request  form. 
The  Administrative  Assistant  will  open  the  Personnel  Data  Window  and  search  the 
database  for  the  member  using  either  the  member's  Social  Security  Number  or  the 
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member's  Last  Name.  If  the  member  is  not  in  the  database  the  member  will  be  entered. 
If  the  member  is  in  the  database  the  record  will  be  checked  for  validity  and  updated  if 
required.  If  the  member  is  in  the  Navy  then  the  NAVPERS  1320  window  is  opened  from 
within  the  Personnel  Data  Window.  If  the  member  is  not  in  the  military  the  DD1610 
Window  is  opened  from  within  the  Personnel  Data  Window.  At  this  point  all  the  data 
entry  fields  of  the  forms  pertaining  to  Personnel  Data  are  automatically  filled  in.  The 
Administrative  Assistant  is  then  tasked  with  completing  the  form.  The  completed  form 
is  then  printed  out  and  delivered. 

In  order  to  complete  the  DD  form  1351,  the  user  enters  the  database  through  the 
Personnel  Data  Window,  finds  the  member,  then  opens  either  the  DD  1610  window  or 
the  NAVPERS  1320  window  whichever  is  appropriate.  The  travel  order  which 
corresponds  to  the  requested  DD1351  must  be  displayed  on  the  screen.  The  user  then 
selects  DD  1351  and  the  data  entry  window  is  opened  with  all  previously  entered  data 
automatically  displayed.  The  administrative  assistant  then  enters  the  remaining  data, 
prints  the  report,  and  submits  it  to  the  appropriate  office. 

The  diagram  depicted  in  Figure  5  is  a  representation  of  the  menu  hierarchy.  In  this 
database  application  the  menu  hierarchy  is  a  direct  representation  of  the  underlying  data 
structure. 
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Figure  5.  Menu  Hierarchy 
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TABLE  1.  DATA  FILES 


FILE  NAME 


TYPE 


DESCRIPTION 


PERSDATA.DF1  DATA 

DD1610.DF1  DATA 

NP1320.DF1  DATA 

DD1351.DF1  DATA 


ATTRIBUTES  OF  PERSONNEL  DATA  FILE 
ATTRIBUTES  OF  DD  1610 
ATTRIBUTES  OF  NAVPERS  1320\B 
ATTRIBUTES  OF  DD  1351 
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TABLE  2.  FILE  FORMAT  PERSDATA.DF1 


Element 


Type 


LAST_NAME  Character 
FIRST_NAME  Character 
MIDDLE  INITIAL   Character 


Width 


Description 


POSITION 

SSN 

PHONE_NUMBER 

DEPARTMENT 

CLEARANCE 

OFF_STA 

ORG  ELE 


Character 
Character 
Character 
Character 
Character 
Character 
Character 


TYPE_TRAVELER  Character 

DESIGNATOR  Character 

STREET_ADDRESS  Character 

CITY  Character 

STATE  Character 

ZIP_CODE  Character 

RANK_1  Character 

SERVICE  1  Character 


15  IND 
15  IND 

1 
35 

11  IND 
13 
15 
15 
30 
30 
10 

4 
30 
10 

2 

5 

6 

6 


last  name 
first  name 
middle  initial 


Security  clearance 
Official  Station 
Organizational  Element 


Record  length  is  between  26  and  338  bytes 

1000  records  may  use  between  141000  and  615000  disk  bytes 
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TABLE  3.  FILE  FORMAT  DD1610.DF1 


Element 

Tvpe 

W: 

Ldth 

Description 

REQUEST  DATE 

Date 

D 

m  Y 

Block  1 

PROCEED_DATE 

Date 

D 

m  Y 

Block  10b 

PURPOSE 

Character 

280 

Block  9 

ITINERARY 

Character 

42 

Block  11 

RETURN_DATE 

Date 

D 

m  Y 

Included  in  Block  11 

APPOX  DAYS 

Character 

10 

Block  10a 

TYPE_ORDERS 

Character 

5 

Block  7 

VAR_AUTH 

Character 

1 

Included  in 

Block  11 

Variation  Authorized 

COM_RAIL 

Character 

1 

Block  12 
Commercial  Rail 

COM_AIR 

Character 

1 

Block  12 
Commercial  Air 

COM_BUS 

Character 

1 

Block  12 
Commercial  Bus 

COM_SHIP 

Character 

1 

Block  12 
Commercial  Ship 

GOV  AIR 

Character 

1 

Block  12 
Government  Air 
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TABLE  3,  cont. 


GOV  VEH 


GOV  SHIP 


Character 


Character 


RATE  PER  MILE    Number 


ADV  GOVT 


REIMBURS 


Character 


Character 


PER  DIEM  AUTH    Character 


OTHER  PER  DIEM   Character 


AS  DET 


Character 


EST  PER  DIEM     Number 


EST  TRV  COST     Number 


EST  OTHER       Number 


EST  TOTAL 


Number 


ADV  AUTHORIZED   Character 


REMARKS 


Character 


1     Block  12 

Government  Vehicle 
1     Block  12 

Government  Ship 
2  dp     Block  12 

Rate  Per  Mile 
1     Block  12 

Advantage  Gov't 
1     Block  12 

Reimbursement 
1     Block  13 

Per  Diem  Authorized 
1     Block  13 

Other  Per  Diem  Rate 
1    Block  12 

Overseas  travel 
only 
2  dp     Block  14 

Estimated  Per  Diem 
2  dp     Block  14 

Est.  Travel  Cost 
2  dp     Block  14 

Other  Expenses 
2  dp     Block  14 

Estimated  Total 
5     Block  14 

Advance  Authorized 
420     Block  16 


15 


TABLE  3,  cont. 

REQJDFF 

APP_OFF 

APP_SUB_1 
APP_SUB_2 
APP    SUB    3 


Character 

Character 

Character 
Character 
Character 


30      Block  17 

Requesting  Official 
30      Block  17 

Approving  Official 
16     Block  19 
16     Appropriation 
16     and  Subhead 


OBJ_CLASS_l 
OBJ_CLASS_2 
OBJ  CLASS  3 


Character 
Character 
Character 


Block  19 
Object  Class 


BUNO_l 
BUNO_2 
BUNO  3 


Character 
Character 
Character 


6     Block  19 

6    Bureau  Control 

6     Number 


SUB_AUTH_1 
SUB_AUTH_2 
SUB  AUTH  3 


Character 
Character 
Character 


3     Block  19 
3     Sub-auth 

3 


AUTH_ACCT_1 
AUTH_ACCT_2 
AUTH  ACCT  3 


Character 
Character 
Character 


8     Block  19 

8     Authorizing 

8     Acct.  Activity 


TYPE_1 
TYPE_2 
TYPE  3 


Character 
Character 
Character 


Block  19 
Type 
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TABLE  3,  cont. 

TANGO_NO_l 
TANGO_NO_2 
TANGO  NO  3 


Character 
Character 
Character 


6     Block  19 

6     Travel  Order 

6     Number 


COST_CODE_l 
COST_CODE_2 
COST  CODE  3 


Character 
Character 
Character 


15 

Block  19 

15 

Cost  Code 

15 

ORD  AUTH  OFF 


Character 


15     Block  20 
Order 

Authorizing 
Official 


ISSUE  DATE 


Date 


D  m  Y     Block  21 

Date  Issued 


TRAVEL  ORD  NO    Character 


20  IND 


Block  22 
Travel  Order 
Number 


Record  length  is  between  136  and  1720  bytes 

1000  records  may  use  between  226000  and  2527000  disk  bytes 
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TABLE  4.  FILE  FORMAT  NP1320.DF1 


Element 


FROM_l 
STAN  DOC  NO 


Type 


Character 
Character 


Width 


Description 


60 


Block  1 


12  IND   Block  2 
Standard 
Document  Number 


TANGO_NO 

Character 

12 

Block 

4 

DATE 

Date 

D  m 

Block 

6 

REF_A 

Character 

40 

BLOCK 

7 

INDIVIDUAL 

Character 

1 

BLOCK  8 

Individual 

Travel 

GROUP 

Character 

1 

BLOCK 
Group 

8 
Travel 

PROCEEDJDN 

Date 

D  m  Y 

Block 

9 

AUTH_PROCEED 

Date 

D  m  Y 

Block 

10 

APPROX_DAYS 

Character 

10 

Block 

11 

EST_RETURN_DATE 

Date 

D  m  Y 

BLOCK 

12 

ITINERARY 

Character 

240 

Block 

13 

TEMADD 

Character 

1 

BLOCK  14 

TEMADD 

TEMADDCON 

Character 

1 

BLOCK  14 
TEMADDCON 

TEMADDINS 

Character 

1 

Block  14 
TEMADDINS 

REASON 

Character 

120 

BLOCK 

15 

AUTH_VISIT 

Character 

1 

Block 

16 

APP  SYM  1 

Character 

7 

Block 

17 

18 


TABLE  4,  cont. 


APP_SYM_2 

Character 

7 

Appropriation 
symbol 

APP_SYM_3 

Character 

7 

SUB  HEAD_1 

Character 

4 

Block  17 

SUB  HEAD_2 

Character 

4 

Appropriation 
Subhead 

SUB  HEAD_3 

Character 

4 

OBJECT_l 

Character 

3 

Block  17 

OBJECT_2 

Character 

3 

Object  Class 

OBJECT_3 

Character 

3 

BU_CONT_l 

Character 

4 

Block  17 

BU_CONT_2 

Character 

4 

BU  CONT  NUMBER 

BU_CONT_3 

Character 

4 

SUB_ALLOT_l 

Character 

5 

Block  17 

SUB_ALLOT_2 

Character 

5 

Sub-Allot 

Number 

SUB_ALLOT_3 

Character 

5 

AUTH_ACCTG_1 

Character 

6 

Block  17 

AUTH_ACCTG_2 

Character 

6 

Authorized 

ACCTG 

AUTH  ACCTG  3 

Character 

6 

Activity 

TY_1 

Character 

2 

Block  17 

TY_2 

Character 

2 

TYPE 

TY_3 

Character 

2 

ACCTG  ACTY  1 

Character 

6 

Block  17 
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TABLE  4,  cont. 


ACCTG_ACTY_2  Character 

ACCTG_ACTY_3  Character 

CC_1  Character 

CC_2  Character 

CC_3  Character 

TRANSPORTATION  Number 


PERDIEM 

MISC_EXP 

TOTAL_EXP 

CUST_ID_CODE 

ITEM 

COMMENTS 

AUTH_SIG 

TRANS_REQUEST 

COPY  TO 


Number 

Number 

Number 

Character 
Character 
Character 
Character 
Character 
Character 


6 

PROPERTY 

ACCTGACTY 

6 

12 

Block 

17 

12 

Cost  Code 

12 

2  dp 

Block 

18 

Transportation 

2  dp 

Block 

18 

Per  Diem 

2  dp 

Block 

18 

Misc. 

Exp 

2  dp 

Block 
Total 

18 

18 

Block 

19 

120 

Block 

20 

400 

Block 

21 

40 

Block 

23 

240 

Block 

24 

40 

Block 

25 

Record  length  is  between  122  and  1780  bytes 

1000  records  may  use  between  199000  and  2598000  disk  bytes 
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TABLE  5.  FILE  FORMAT  DD1351.DF1 


Element 


Type 


Width    Description 


PRIOR  PAY 


Character     40     Prior  travel 

payments  or 
advances  under  these 
orders 


DEP  1 

Date 

D  m 

Y 

ARR  1 

Date 

D  m 

Y 

DEP  2 

Date 

D  m 

Y 

ARR  2 

Date 

D  m 

Y 

DEP  3 

Date 

D  m 

Y 

ARR  3 

Date 

D  m 

Y 

DEP  4 

Date 

D  m 

Y 

ARR  4 

Date 

D  m 

Y 

DEP  5 

Date 

D  m 

Y 

ARR_5 

Date 

D  m 

Y 

DEP  6 

Date 

D  m 

Y 

ARR  6 

Date 

D  m 

Y 

DEP  7 

Date 

D  m 

Y 

ARR_7 

Date 

D  m 

Y 

TIME  1 

Short 

time 

TIME  2 

Short 

time 

TIME  3 

Short 

time 

TIME  4 

Short 

time 

TIME  5 

Short 

time 

TIME  6 

Short 

time 

TIME  7 

Short 

time 

TIME  8 

Short 

time 

TIME  9 

Short 

time 

TIME  10 

Short 

time 

TIME  11 

Short 

time 

TIME  12 

Short 

time 

TIME  13 

Short 

time 

TIME_14 

Short 

time 

PLACE  1 

Character 

15 

PLACE  2 

Character 

15 

PLACE  3 

Character 

15 

PLACE  4 

Character 

15 

PLACE  5 

Character 

15 

PLACE  6 

Character 

15 

PLACE  7 

Character 

15 

PLACE  8 

Character 

15 

Block  1:  Dates 


Block  1 :  Times 


Block  1:  Place 
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TABLE  5,  cont. 


MODE_l 

MODE_2 
MODE_3 
MODE_4 
MODE_5 
MODE_6 
MODE_7 
STOP_l 

STOP_2 
STOP_3 
STOP_4 
STOP_5 
STOP_6 
STOP  7 


Character 


Chara 
Chara 
Chara 
Chara 
Chara 
Chara 
Chara 


cter 
cter 
cter 
cter 
cter 
cter 
cter 


Character 
Character 
Character 
Character 
Character 
Character 


Block  1 
travel 


Mode  of 


Block  1 :  Reason 
for  stop 


C0L_1 

C0L_2 
C0L_3 
C0L_4 
C0L_5 
C0L_6 
C0L_7 

MEALS_G_1 

MEALS_G_2 
MEALS_G_3 
MEALS_G_4 
MEALS_G_5 
MEALS_G_6 
MEALS_G_7 

MEALS_D_1 

MEALS_D_2 
MEALS_D_3 
MEALS_D_4 
MEALS_D_5 
MEALS_D_6 
MEALS_D_7 

0M_1 

0M_2 
OM  3 


Number 

Number 
Number 
Number 
Number 
Number 
Number 

Integer 

Integer 
Integer 
Integer 
Integer 
Integer 
Integer 

Integer 

Integer 
Integer 
Integer 
Integer 
Integer 
Integer 

Integer 

Integer 
Integer 


2  dp 

Block  2: 
lodging 

Cost  of 

2  dp 

2  dp 

2  dp 

2  dp 

2  dp 

2  dp 

(0  to 

255) 

Block  3: 
Meals\Govt 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

Block  3: 
Meals\Ded 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

(0  to 

255) 

Block  3:  Open 
Mess 

(0  to 

255) 

(0  to 

255) 
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TABLE  5,  cont. 


OM_4 
OM_5 
OM_6 
OM_7 

POC_MILES_l 
POC_MILES_2 
POC_MILES_3 

POC_MILES_4 
POC_MILES_5 
POC_MILES_6 
POC_MILES_7 

DATE_1 
DATE_2 
DATE_3 
DATE  4 


Integer 
Integer 
Integer 
Integer 

Number 
Number 
Number 

Number 
Number 
Number 
Number 

Date 
Date 
Date 
Date 


(0  to  255) 

(0  to  2  55) 

(0  to  255) 

(0  to  255) 


0  dp 
0  dp 
0  dp 

0  dp 
0  dp 
0  dp 
0  dp 

D  m  Y 

D  m  Y 

D  m  Y 

D  m  Y 


Block  4 :  POC  Miles 


Block  5:  Date 


N  E  1 


N 

n" 
n" 

E 

"e" 
"e" 

2 
"3 

"4 

AMT 

CLAIM 

AMT_CLAIM_2 
AMT_CLAIM_3 
AMT_CLAIM_4 

ALLOWED_l 
ALLOWED_2 
ALLOWED_3 
ALLOWED  4 


Character 

Character 
Character 
Character 

Number 

Number 
Number 
Number 

Number 
Number 
Number 
Number 


20 

20 
20 
20 

2  dp 


dp 
dp 
dp 

dp 
dp 
dp 
dp 


Block  5 :  Naure 
Explanation 


Block  5:  Amt. 
Claimed 


Block  5:  Allowed 


APPR  OFFICER 


Character 


15 


Block  6:  Approving 
Officer 


NUMBER_1 
NUMBER  2 


Character 
Character 


20 
20 


Block  7 :  Number 


FROM1 
FROM2 


Character 
Character 


20 
20 


Block  7:  From 


TOl 
T02 


Character 
Character 


20 
20 


Block  7:  To 
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TABLE  5,  cont. 


LEAVE 


HOURS 


Integer 
Integer 


0  to  255   Block  8:  Leave 
days 

0  to  255   Block  8:  Leave 
hours 


DATE_8 

Date 

D 

m 

Y 

Block 
date 

8: 

Start 

DATE_9 

Date 

D 

m 

Y 

Block 
date 

8: 

End 

POC_OWNER 

Character 

1 

Block 

9: 

POC 

Owner 

POC_PASS 

Character 

1 

Block 

9: 

Passenge: 

c 

CHECK 

Character 

1 

Block 

11: 

Check 

CASH 

Character 

1 

Block 

11: 

Cash 

PER_DIEM_REQ 

Character 

1 

Block 

12: 

Per 

Diem  Requ< 

ssted 

Record  length  is  between  436  and  966  bytes. 

1000  records  may  use  between  518000  and  1408000  disk  bytes 
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IV.  EVALUATION  PHASE 

The  evaluation  phase  actually  consists  of  three  tasks,  all  focused  on  redefining  the 
scope  and  feasibility  of  the  entire  project.  The  first  phase  is  determining  alternatives  to 
the  proposed  solution.  Secondly  the  feasibility  of  the  project  is  re-evaluated  based  on  the 
more  detailed  specifications  which  are  now  available  to  the  designers.  Finally  all  user 
requirements  are  evaluated  within  the  scope  of  the  alternative  solutions.  [Ref.  3:pg.  78] 

The  evaluation  phase  will  be  effective  only  if  a  thorough  understanding  of  the 
system  requirements  is  achieved  during  the  earlier  phases  of  development.  It  was  decided 
early  on  that  using  the  OMNIS7  Integrated  Development  Environment  would  provide  for 
the  development  of  a  graphical  user  interface  which  would  facilitate  learning  by  end 
users.  The  hardware  requirements  were  determined  to  be  of  minimal  concern  as  there  is 
an  ample  supply  of  personal  computers  within  the  Administrative  Sciences  Department. 

It  was  decided  that  the  choice  of  printer  would  be  delayed  until  the  TDS  prototype 
was  installed.  This  would  allow  the  developer  to  evaluate  the  printers  available  in  the 
Administrative  Sciences  Department  and  select  the  one  best  suited  for  the  application. 

The  application  is  designed  using  a  structured  approach.  The  only  possible  obstacle 
foreseen  was  the  process  of  learning  how  to  manipulate  a  very  powerful  database 
development  environment.  Otherwise  it  was  still  well  within  the  realm  of  possibility  for 
this  project  to  be  completed  within  the  expanded  time  constraints. 
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development  environment.  Otherwise  it  was  still  well  within  the  realm  of  possibility  for 
this  project  to  be  completed  within  the  expanded  time  constraints. 
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V.  DESIGN  PHASE 

The  objective  of  the  design  phase  is  to  develop  a  blueprint  for  the  database  and  its 
associated  applications.  During  this  phase  the  development  team  establishes  the  database 
schema,  the  application  sub-schema,  formats  for  forms,  reports,  menus  as  well  as  the 
underlying  logic.  The  mechanisms  for  update  display  and  control  are  also  determined  at 
this  time.  After  the  database  has  been  designed  the  team  can  design  each  application 
which  consists  of  a  collection  of  menus,  forms  reports  and  programs  which  meet  the 
specific  user  needs.  [Ref.  3:pg.  79] 

A.      NORMALIZATION 

The  goal  of  a  logical  database  is  to  represent  objects  in  the  database  using  relations. 
The  construction  of  user  objects  so  that  rows  of  data  can  be  inserted,  deleted,  and 
modified  without  resulting  inconsistencies  or  errors  is  paramount.  The  deletion  anomaly 
occurs  when  one  object  is  deleted  and  has  the  effect  of  deleting  data  from  another  object 
instance.  The  insertion  anomaly  occurs  when  data  cannot  be  inserted  into  one  entity  until 
data  is  known  about  another  entity.  These  conditions  can  cause  serious  problems  in 
database  design.  The  current  design  has  all  its  relationships  ,  as  defined  in  Tables  1-5, 
in  Boyce-Codd  Normal  Form. 
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B.       PHYSICAL  DATABASE  DESIGN 

The  four  file  formats  involved  in  the  Travel  Database  system  are  delineated  in 
Tables  1  through  5.  The  key  attributes  (SSN,  TRAVEL_ORD_NO,  and 
STAN_DOC_NO)  are  noted  with  an  asterisk.  Their  relationship  to  one  another  is 
graphically  represented  in  Figure  2.  In  the  OMNIS7  environment  the  unique  key  attribute 
is  used  to  functionally  define  each  relation,  in  other  words,  the  remaining  attributes  of 
an  object  are  associated  in  that  file  format  to  that  unique  key.  As  an  illustration,  only  one 
record  may  have  a  particular  SSN  in  the  PERSDATA  file.  Likewise  only  one  travel 
order  may  be  linked  to  a  unique  Travel  Order  Number,  although  several  travel  orders 
may  belong  to  one  SSN.  The  relations  are  linked  using  OMNTS7's  record  sequencing 
number  (RSN)  feature. 

The  RSN  feature  takes  care  of  the  requirement  to  carefully  arrange  relational  joins 
to  avoid  anomalies.  For  instance,  if  a  personnel  record  is  deleted,  all  of  that  person's 
travel  orders  and  travel  claims  are  still  available.  Likewise,  a  travel  claim  or  travel  order 
can  be  deleted  without  affecting  the  associated  personnel  record. 
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VI.  IMPLEMENTATION  PHASE 

The  final  phase  of  the  process  is  implementation.  The  details  of  the  implementation 
depend  a  great  deal  on  the  DBMS  being  used.  OMNIS7  is  a  very  powerful  program  and 
nearly  all  of  the  requirements  could  be  generated  by  the  automatic  code  generation 
features  of  the  development  environment.  This  feature  reduced  the  amount  of  effort 
required  in  the  initial  phase  of  implementation.  Testing  and  installation  are  the  final  two 
stages  of  the  implementation  phase.  [Ref.  3:pg  81] 

A.      PROGRAMMING 

The  goal  of  this  phase  is  to  construct  the  system  as  designed.  The  powerful  nature 
of  the  OMNIS7  Development  Environment  did  not  require  a  great  deal  of  custom  coding 
(creating  procedures  in  OMNIS7  parlance).  Those  custom  procedures  which  were  coded 
are  included  in  Tables  6  through  9.  The  majority  of  the  code  is  generated  automatically 
by  OMNIS7  and  is  therefore  transparent  to  the  developer.  Procedures  can  be  initiated  for 
any  field  on  any  window  or  custom  pushbuttons  can  be  generated.  The  code  written  for 
this  application  facilitated  report  printing. 


29 


TABLE  6.  CUSTOM  PROCEDURES  -  PERSONEL  WINDOW,  W  PERS  DATA 

0.  Initial  Control  Procedure 

Set  Main  File  {FPERS  DATA} 
Prepare  for  insert 

24.  DD  1610  (pushbutton) 

Open  window  W_DD1610 

25.  NAVPERS  1320  (pushbutton) 

Open  window  NAVPERS  1320 

TABLE  7.         CUSTOM  PROCEDURES  -  NAVPERS  1320  WINDOW, 
NAVPERS  1320 

66.  PRINT  NAVPERS  1320  (pushbutton) 

Set  report  name  RDNAVPERS  1320 

YES/NO  message  (Large  size)  {Print  Standard  Document  Number 

[STANDOCNO]  for  [FIRSTNAME]  [LASTNAME]  ?} 

If  flag  true 

Prepare  for  print 

Print  record 

Print  totals 

End  if 
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67.  DD  1351  (pushbutton) 

Open  window  W_DD1351 

TABLE  8.  CUSTOM  PROCEDURES  -  DD  1610,  W  DD1610 

72.  PRINT  DD  1610  (pushbutton) 

Set  report  name  DD_1610 

YES/NO  message  (Large  size)  {Print  Travel  Order  Number 
[TRAVELORDNO]  for  [FIRSTNAME]  [LASTNAME]  ?} 
If  flag  true 

Prepare  for  print 

Print  record 

Print  totals 
End  if 

73.  DD  1351  (pushbutton) 

Open  window  WDD1351 
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TABLE  9.  CUSTOM  PROCEDURES  -  DD  1351,  W  DD1351 

72.  PRINT  DD  1351  (pushbutton) 
Set  report  name  DD_1351 

YES/NO  message  (Large  size)  {Print  DD  1351  for  [FIRST_NAME] 
[LASTNAME]  ?} 
If  flag  true 

Prepare  for  print 
Print  record 
Print  totals 
End  if 


B.       TESTING  AND  INSTALLATION 

The  TDS  was  tested  as  a  complete  unit,  although  it  consists  of  three  separate 
modules.  The  system  was  installed  on  an  Administrative  Sciences  Department  PC  and 
test  data  was  entered.  Some  format  errors  were  discovered  on  the  data  input  screens, 
which  were  corrected  immediately.  Some  errors  were  also  found  in  connection  with 
report  output.  Upon  careful  examination  of  these  errors  it  was  concluded  that  the  existing 
printer  could  not  support  the  application.  A  new  printer  was  therefore  procured  and  all 
errors  were  subsequently  eradicated  from  the  system. 
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VII.  CONCLUSION 

The  Travel  Database  System  is  currently  installed  in  the  Administrative  Sciences 
Department  Support  Staff  Office  and  is  running  in  accordance  with  the  design 
specifications.  The  users  have  indicated  satisfaction  with  the  system  although  it  is  not 
being  used  to  the  fullest.  The  result  of  maximizing  the  use  of  this  system  would 
undoubtedly  be  an  increased  productivity  and  a  more  uniform  output  from  the  office. 

The  integration  of  an  accounting  system  with  TDS  would  further  the  department's 
dependency  upon  these  applications.  This  would  improve  user  acceptance  of  the  computer 
in  the  work  space.  The  generation  of  future  applications  using  OMNIS7  is  highly 
recommended. 

Future  upgrades  to  the  existing  system  can  be  readily  determined  as  well.  A  series 
of  reports  highlighting  accounting  data  and  travel  as  well  as  further  automation  of  data 
retrieval  are  just  two  examples. 
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APPENDIX  A. 
USERS  GUIDE  TO  THE  ADMINISTRATIVE  SCIENCE  DEPARTMENT'S 

TEMADD  DATABASE  SYSTEM 


A.  INTRODUCTION 

The  purpose  of  this  manual  is  to  familiarize  the  user  with  the  Administrative 
Sciences  Department's  TEMADD  Database  System  (TDS).  The  system  is  linked  through 
a  series  of  windows  or,  for  more  experienced  users,  a  series  of  pull  down  menus.  The 
system  is  designed  to  be  easy  to  use  but  does  require  some  familiarity  with  Microsoft 
Windows  and  the  use  of  a  mouse. 

B.  GETTING  STARTED 

Before  running  TDS,  the  OMNIS7  Integrated  Development  Environment  and 
Microsoft  Windows  must  be  installed  as  specified  in  their  respective  user's  manuals.  The 
application  file  TRAVEL.  APP  must  be  loaded  onto  the  hard  drive.  The  hard  disk  storage 
space  required  is  4  MB.  The  data  files  can  be  maintained  on  a  floppy.  To  run  the 
application  from  the  prototype  software  the  user  must  first  initialize  Microsoft  Windows. 
The  following  steps  will  guide  the  user  to  the  PERSONNEL  window. 

1.  From  PROGRAM  MANAGER  select  the  OMNIS7  Icon  and  initialize  the 
OMNIS7  Integrated  Development  Environment. 

2.  From  OMN1S7  Bar  Menu  select  FILE.  Select  OPEN  APPLICATION  from  the 
pull  down  menu.  See  Figure  A-l. 
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n!3!^jeTp 

N''W  "iMilii    :'jiii| 

Qptn  Apsllc»Uoi» ...      Clr1«0 

<Qlcsc  Application 
&avt:  Ap|ilitar(<o(i 
Saye  A  CopyAi... 

Password... 
Change  Oafln  Files... 
Hfpor*  OcsHnatinn,.. 
Paye  Cetyp... 

Menu*                                    ► 
Long  Menus 

About  Omnia  7— 

Figure  A-l.  Initialization  Pull  Down  Menu 
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3.     Highlight  TRAVEL. APP  from  the  pop-up  menu  and  press  <  enter  >  .  See  Figure 

A-2. 


iclrrt  application 


FleQaae:    baveLapp 


D  ■setoff:   c:\omnts\thedt_a 

fj**:  Djrectoriet: 


I  ] 
l-b-l 


13  Single  *mx  mode 


Figure  A-2.  Select  Application  Pop-Up  Menu 
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4.     Select  DESIGN  from  the  OMNIS7  bar  menu.  Next,  select  MEXU  FORMATS. 
from  the  pull  down  menu.  See  Figure  A-3. 


£Het*tl               pJ!lm>B^b«lp 

Die  F  of  mala... 
Window  Formats.. 
Qeport  Formats ... 

Scare*  Formats... 

UstFlcU  Names          FS 

Close  lap  Window 
CTose  Qther  Windows 
Close  A"  Windows 

Figure  A-3.  Design  Pull  Down  Menu 
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5.     Highlight  TRAVEL  from  the  pop-up  menu  and  Select  the  INSTALL  option  from 
the  buttons  on  the  right  hand  side  of  the  pop-up  menu.  See  Figure  A-4. 


Figure  A-4.  Menu  Formats  Pop-Up  Menu 
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6.  The  TRAVEL  menu  will  now  be  installed  in  the  bar  menu. 

7.  Highlight  the  TRAVEL  selection  from  the  bar  menu.  The  PERSONNEL  option 
will  be  highlighted.  See  Figure  A-5. 


P^t3irDe8^^5«««^^                   tie'p 

DO  1610 
NAVPERS132t 

DO  13S1 

' 

Figure  A-5.  Travel  Database  Pull  Down  Menu 
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8.     Press  ENTER.  The  PERSONNEL  entry  form  will  come  up  on  the  screen.  See 
Figure  6.  The  TDS  is  now  ready  for  data  entry. 


gig     fc«H     gMJM     UWM—     ggwnwt^     TRAVEL     Mgjp 


LASTMME  FKSTHUC         MOOLE  MTML 


rosmoM 


department 


D 


SSM  jM§  gWTICj  TVPCTRAVH-Bt 

zzn  i 1  I       I    I        I 

oFBa*LST*T»n  oftCWCATiOHAi.  element  wow  number 


1       I  1 


CLEARANCE 


MAIUNG  ADDRESS 

STREET  ADCKESS 


CITY 


STATE 
□ 


zpcox. 


Figure  A-6.  Personnel  Data  Entry  Window 
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C.      PUSH  BUTTONS 

There  are   five  push   buttons  common   to  all   four  data  entry   windows,   the 
pushbuttons  which  are  unique  will  be  described  in  the  data  entry  portion. 


1.  FIND.  The  FIND  button  will  initialize  a  search  on  the  file  until  the  designated 
record  is  found.  If  the  record  is  not  found  the  user  is  told  that  no  match  exists. 
To  use  this  feature  place  the  mouse  over  the  blue  FIND  button  and  depress  the 
left  mouse  button.  The  cursor  will  be  automatically  in  the  data  entry  field  against 
which  the  search  will  be  conducted.  Enter  the  value  (name,  travel  order  number, 
etc.)  which  is  the  unique  value  of  the  record  you  wish  to  find  and  press  ENTER 
or  press  the  OK  push  button.  If  the  record  exists  it  will  be  displayed.  If  you  are 
told  that  the  record  does  not  exist,  check  the  entry  and  try  again. 

2.  EDIT.  The  EDIT  pushbutton  will  prepare  the  record  which  is  currently  displayed 
for  editing.  The  cursor  will  tab  between  fields,  highlighting  the  active  field.  The 
user  may  also  highlight  the  field  by  placing  the  mouse  arrow  directly  on  the  field 
which  is  to  be  edited  and  pressing  the  left  button.  When  the  desired  field  is 
highlighted  the  editing  may  be  completed.  Once  all  of  the  desired  fields  are 
edited,  the  user  must  press  the  OK  button. 

3.  INSERT.  The  INSERT  pushbutton  places  the  cursor  in  the  first  field  into  which 
data  may  be  entered.  Once  a  record  is  completed  the  user  must  press  ENTER  or 
OK. 

4.  OK  and  CANCEL.  These  pushbuttons  are  active  during  the  EDIT  and  INSERT 
operations  and  are  used  to  end  the  process.  OK  allows  the  data  to  be  written  to 
the  file.  CANCEL  simply  ends  the  data  entry  process  without  writing  to  the  data 
file. 


D.      PERSONNEL  DATA  FORM 
1.       Data  Entry 


1 .     Move  the  mouse  over  the  INSERT  pushbutton.  After  the  button  has  been  pressed 
the  cursor  will  be  in  the  LAST  NAME  data  entry  field. 
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2.  Enter  the  required  data  and  <  TAB  >  to  the  next  field.  Once  all  the  required  data 
is  entered  press  the  OK  button  in  the  same  fashion  described  in  step  one. 

3.  To  insert  another  record  repeat  step  one. 

2.  Find\View\Edit  Record 

1.  Position  the  mouse  over  the  find  button  and  depress  the  left  mouse  button. 

2.  The  cursor  will  automatically  move  to  the  LAST  NAME  field. 

3.  At  this  point,  if  the  last  name  is  known,  enter  it  and  press  <  ENTER >.  The 
desired  record  will  appear  in  the  data  entry  form. 

4.  If  the  last  name  is  unknown,  enter  the  first  initial  of  the  last  name  and  press 
< ENTER  >. 

a.  At  this  point,  the  first  record  beginning  with  the  desired  letter  will  appear. 
To  scroll  through  the  records  position  the  mouse  over  the  NEXT 
pushbutton  and  click  with  the  left  mouse  button.  Each  click  will  put  the 
next  record  into  the  data  entry  window.  Continue  clicking  until  the  desired 
record  is  found. 

5.  To  EDIT  the  record  simply  position  the  mouse  over  the  EDIT  pushbutton  and 
depress  the  left  mouse  button.  The  first  data  entry  field  will  be  highlighted.  To 
move  from  field  to  field  press  <  TAB  > . 

6.  Edit  fields  as  desired.  When  the  editing  is  complete  position  the  mouse  over  the 
OK  pushbutton  and  depress  the  left  mouse  button,  or  press  <  ENTER > . 

3.  Delete  Record 

1.  Find  the  Personnel  Record  which  is  to  be  deleted. 

2.  Position  the  mouse  over  the  COMMANDS  selection  from  the  bar  menu. 

3.  Highlight  DELETE. 
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4.  A  confirmation  window  will  pop-up  in  the  bottom  left  hand  corner  of  the  screen. 
If  the  record  is  to  be  deleted,  select  "YES."  If  a  different  record  is  to  be  deleted, 
select  "NO"  and  find  the  proper  record. 

5.  This  option  will  permanently  remove  the  selected  record  from  the  data  base.  It 
is  recommended  that  extreme  caution  be  used  when  exercising  this  option. 

4.       DD  1610  Data  Entry  Form 

a.     Data  Entry 


1.  Initiate  the  DD  1610  Data  Entry  form  the  Personnel  Data  entry  Form.  The 
method  for  doing  this  is  as  follows: 

a.  Once  the  desired  Personnel  Record  has  been  entered  or  found  position  the 
mouse  over  the  DD  1610  pushbutton  and  depress  the  left  mouse  button.  The 
DD  1610  Data  Entry  Form  will  come  up  on  the  screen  with  the  personnel 
data  fields  already  filled. 

2.  In  order  to  initiate  a  new  DD  1610,  position  the  mouse  over  the  INSERT 
pushbutton  and  depress  the  left  mouse  button.  The  database  is  now  ready  to 
accept  a  new  record. 

3.  The  cursor  will  be  positioned  in  the  TYPE  ORDER  data  entry  field.  As  the  data 
is  entered,  tab  from  field  to  field. 

4.  When  all  the  required  data  is  filled  in  press  <  ENTER  >  or  position  the  mouse 
over  the  OK  pushbutton  and  depress  the  left  button. 


b.    Find\View\Edit  Record 


1.  In  order  to  find  a  DD  1610  for  viewing  or  editing  position  the  mouse  over  the 
FIND  button  and  depress  the  left  mouse  button. 

2.  The  cursor  will  be  positioned  in  the  TRAVEL  ORDER  NUMBER  field.  Enter 
the  travel  order  number  which  is  associated  with  the  record  to  be  viewed  or 
edited.  Press  <  ENTER  >  and  the  desired  record  will  be  brought  to  the  screen. 
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3.  To  EDIT  the  record,  position  the  mouse  over  the  field  to  be  edited  and  depress 
the  left  mouse  mountain.  <TAB>  between  fields  and  complete  the  required 
editing.  When  all  the  editing  is  completed  press  <  ENTER  >. 


c.     Delete  a  Record 


1.  If  a  record  is  to  be  deleted,  it  must  be  brought  into  the  data  entry  form  as 
described  in  the  Find\View\Edit  section.  Delete  as  described  in  the  Personnel 
section. 

2.  Exercise  extreme  caution  when  using  this  option.  The  record  will  be  permanently 
removed  from  the  database  if  the  option  is  completed. 


d.     Print  a  DD  1610 


1.  Complete  the  data  entry  for  the  DD  1610. 

2.  Position  the  mouse  over  the  PRINT  DD  1610  pushbutton.  Depress  the  left  mouse 
button. 

3.  A  confirmation  window  will  appear  asking  the  user  to  confirm  the  name  and 
travel  order  number. 

4.  If  the  information  in  the  confirmation  window  is  correct,  select  YES.  If  not, 
select  NO. 

5.  Once  the  form  has  been  printed,  position  the  transparency  over  the  data  sheet  and 
create  a  copy.  This  is  the  original. 


e.     NAVPERS  1320 

The  procedures  for  manipulating  this  form  are  the  same  as  for  the  DD 
1610. 
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/.     DD 1351 

The  procedures  for  manipulating  this  form  are  the  same  as  for  the  DD 
1610  and  NAVPERS  1320. 
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APPENDIX  B 
REQUIRED  FORMS 


Figure  B-l     DD  form  1610 

Figure  B-2     NAVPERS  1320U6 

Figure  B-3    DD  form  1351 
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REQUEST  AND  AUTHORIZATION  FOR  TDY  TRAVEL  OF  DOD  PERSONNEL 

(Reference    Joint  Travel  Regulations) 
Travel    Authorized    M    Indicated    in    Items    2  through   21 


1      DATE  OF 
REQUEST 


2.  NAME  (Last.  First.  Middle  Initial) 


BEQUEST  KM  OfflCIAl  TRAV& 


3.    POSITION  TITLE  AND  GRADE  OR  RATING 


4.    OFFICIAL  STATION 


3.    ORGANIZATIONAL  ELEMENT 


«     PHONE   NO 


7.    TYPE  OF  ORDERS 


10a.  APPROX   NO    OF  DAYS  OF 
TDY  (Including  travel  time) 


8.    SECURITY  CLEARANCE 


9     PURPOSE  OF  TDY 


h.    PROCEED  0/A(D<lie) 


t  I  .    ITINERARY 


I       I     VARIATION    AUTHORIZED 


MODE  OF  TRANSPORTATION 


COMMERCIAL 


GOVERNMENT 


privately  owned  conveyance  (Check  one) 


RATE  PER  MILE 


AS  DETERMINED  BY  APPROPRIATE  TRANSPORTATION 

officer  (Oversea!  Travel  only) 


|        |      MORE   ADVANTAGEOUS  TO  GOVERNMENT 

, ,  MILEAGE     REIMBURSEMENT     AND     PER     DIEM     LIMITED     TO    CON- 

_]  STRUCTIVE  COST  OF  COMMON  CARRIER  TRANSPORTATION  » 
RELATED  PER  OIEM  AS  DETERMINED  IN  JTR  travel  TIME  LIMITED 
AS  INOICATED  IN  JTR 


,3'                   □  PER  0IEM  AUTHORIZED  IN  ACCORDANCE  WITH   JTR 
I      1  OTHER  RATE  OF  PER  DIEM  (Specify) 


ESTIMATED  COST 


%  |_i Li l_l l » 

16.  REMARKS(i/j*  this  space  /or  special  requirements,   leave,  superior  or  1st  class  accommodations,  excess  baggage,  registration  feet,  etc.) 


IS.   ADVANCE 

AUTHORIZED 


17.   REQUESTING  OFFICIAL  (Title  and  signature) 


18.   APPROVING  OFFICIALfTitle  and  signature) 


AUTHORIZATION 


APPROPRIATION 
AND 


OBJECT 
CLASS 


BUREAU 
CONTROL 

NUMBER 


sua 

AUTM 


AUTHORIZATION 

ACCOUNTING 

ACIIVf  I  V 


TRAVEL  ORDER 

(Tango)no 


COST  CODE 


20.    ORDER  AUTHORIZING  OFFICIALf77/fcf  and  Signature)  OR  AUTHENTICATION 


2 I     DATE  ISSUED 


22     TRAVEL  ORDER  NUMBER 


DD    i^SnTt      1610  ""    O'Ol    ir    01«    J702 


NAVY  OVERPRINT     JAN    l»7l 


Figure  B-l.  DD  form  1610 
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TEMPORARY  ADDITIONAL  DUTY  (TEMADD)  TRAVEL  ORDERS 


1    FROM: 


2.  STANDARD  DOCUMENT  NO. 


3    TO 


4.  TANGO  NO. 


5    SSN/OESIGNATOR 


6    DATE 


7    REF  (A) 


□  HOIVOUAL 


travel 


□GROUP 
TRAVEL 


9    PROCEED  ON  OR  ABOUT 


10    AUTHORIZED  PROCEED  ON  OR 
ABOUT 


11.  APPROXIMATE  NUMBER  OF 
DXYS 


12.  ESTIMATED  DATE  OF  RETURN 


13     ITINERARY  i  Activity  activities  and  Place  places  indicated  ootow) 


14 


D 


D 


TEMADOCON 


□ 


15    REASON  FOR  TRAVEL 


,6.      ,-, 


AUTHORIZED  VISIT  SUCH  ADOmOHAL 
PLACES  AS  MAY  BE  NECESSARY 
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FISCAL  DATA  ACCOUNTING  CLASSIFICATION 


APPROPRIATION 

SYMBOL  AND  SUB-HEAD 

(1)  (2) 


OBJECT 

CLASS 

(3) 


BU  CONT 

NUMBER 

(4) 


SUB  ALLOT 

NUMBER 

(5) 


AUTHORIZED 

ACCTG  ACTY 

(6) 


TYPE 
(7) 


PROPERTY 

ACCTG  ACTY 

(8) 


COSTCOOE 
(9) 


(7  SYM) 


(4  SYM) 


(3  SYM) 


(5  SYM) 


(1  SYM) 


(6  SYM) 


(2  SYM) 


(6  SYM) 


(12  SYM) 
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ESTIMATED  COST 


19.  CUSTOMER  IDENTIFICATION  CODE 


TRANSPORTATION 
$ 


PER  DIEM 
$ 


MISC  EXP. 
$ 


TOTAL 

$ 


20    ITEM.  (Use  applicable  Hem  number*  as  thown  on  reverse  side  ot  ttus  term) 


Report  to  a  Disbursing  Officer  within  10  days  after  completion  of  travel  to  settle  your  travel  expenses " 


22.  SECURITY  CLEARANCE: 
tT  IS  CERTIFIED  THAT  YOU 
HOLD  A 


21    ADDITIONAL  COMMENTS  AND  INSTRUCTIONS: 


BASED 

COMPLETED . 
BY 


(PLUS 

YEARS  SERVICE) 


23    AUTHENTICATING  SIGNATURE 


24    TRANSPORTATION  REQUEST/MAC  TRANSPORTATION  AUTHORIZATION  FURNISHED 


25    COPY  TO    (Include  Operating  Budget  fund  manager  in  all  cases) 


NAVPERS  1320  16  (Rev.  11-87)        S  N  0106-LF-013-20B2 


Figure  B-2.  NAVPERS  1320/16 
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S/N0102-LF-0 13-2803 


(Compiete  5J  typewriter,  ink,  oe  boll 

point  pen /PRESS  HARD)  do  not  use  pmcil) 


TRAVEL  VOUCHER  OR  SUBVOUCHER 


READ  PRIVACY  ACT  STATEMENT  OH  REVERSE  PRIOR  TO  COMPLETING  THIS  FORM 

LAST  NAME   FIRST  NAA4E    UICXXE  INITIAL (Pnnti Trjte)  |  ORADE/RANK     |  SSN 


CHECK  MAILING  ADDRESS  (Include  ZIP  Cade) 


ORGANIZATION  ANO  STATION 


txmr  phone  no 


TRAVEL  OROERS," 


S  O  No,  laving  Hq  .  Oo<o  (Include  emending  orders) 


PRIOR  TRAVEL  PAYMENTS  OR  ADVANCES  UNDER  THESE  ORDERS  lAmounl.  DO  Voucher  No  .  Dole  Received,  Piece  paid. 
or  DO  Station  No.  If  normz.  JO  unlet 


rngifiARV  (See  Item  11  for  Srmbotii 


OATE 
t» 


LOCAt  TIME 
(14  Hot  OoctJ 


PLACE 
IHome.  Office.  Base.  Acttruy.  City 
end  Store.  Ciir  end  Country,  etc  ) 


h 


COST 

OF 

LOCOING 


3      NUMBCR 
OF  MEALS 


OPEN 
MESS 


POC 
MILES 


FOR  DO  USE  ONL  Y 


00  VOUCHER  NO 


SUBVOUCHER  10 


PAID  BY 


COMPUTATIONS 


REIMBURSABLE  EXPENSES/CHARGE  FOR  DEDUCTIBLE  MEALS  ■  (See  hem  HI 


NATURE  ANO  EXPLANATION 


AMT  CLAIMED 


SUMMARY  OF  PAYMENT 


Per  Diem 


Actual  Expanee 


8      Long  dtMinccttVprtoat  cilh  •recenirVd  H  mcoutj  m  the 
iiHCTrn  o/lH?( 


APPROVING  OFFICER  131  USC  M0o> 


Mileage  or  Tranap  Allowance* 


Reimbursable  Expenses 


TR  S/UTA  S/MT-8(l/«o«l*.  tot-m 


Total  Entitlement 


Last  Previous  Payments 


Lesa  Voucher  Deducttona 


Arm  Charged  to  Acctg  Claaa 


11  PAYMENT  DESIRED 

□  CHECK 


D  CASH 


•    LEAVE  STATEMENT 


.Of. 


■"•0UH  uton  b#tW**f> 


D  PER  DIEM  REOUESTEO 


•    POCTTUVEL 


D  0WNER/OPERATORrt*r/wm 


lid  I 


D  PASSENGER 


13   BASPATE 


PENALTY   The  penalty  tor  wWtuffy  m«*ing  ■  Wt*  Otem  »  A  MAXIMUM  FINE  OF  110.000  0*  MAXIMUM  IMPR ISONMENT  OF  »  YEARS.  OR  BOTH  (V  S  Code.  Tide  It.  Section  It  1 1 


I    hereby    dam    any    imount    due    me     TV    rutememt    or*    fjce.    reverie,    ind 
■ttjcKed    ire    inte    ind    complete     Parmcni    or    credit    h«i    nor    been    nctrraj 


14    SIGNATURE  OF  CLAIMANT 


DATE 


15    ACCOUNTING  CLASSIFICATION 


IS    COLLECTION  DATA 


17    COMPUTED  BY 


18    AUCXTEOBY 


1»    TVLRCRD  POSTED 
BY 


20    R£CEIV£D  (Pteee  ugnorure  and  dote  or  check  no  I 


21  AMOUNT  PAID 


nil    F°RM    iOCI  O  Exception  to  SF  1012  and  1012a 

■III  1  JUNTf   I  a)  9  I  - —  aC  EDITION  OF    1  JUL  65  WILL  BE   USED  UNTIL  EXHAUSTED  approved  by  NARS,  CSA  Apnl  1979. 


Figure  B-3.  DD  form  1351 
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